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Optimized transmission of Text Sample Format Descriptions 

for streaming Timed Text 

- • 

* 

Field of Invention 

The present invention relates to a method for transmitting formatted text from a 
5 streaming server to a mobile client using an RTP protocol in a mobile communication 
system. The formatted text may comprise at least one text sample having an associated 
text sample format description. Further, the present invention relates tb the streaming 
server transmitting, the formatted text, the mobile client receiving a streamed formatted 

* • * 

text and to a system comprising the streaming server arid the mobile client. 
10 Background Art 

The 3GPP (3 rt Generation Partnership Project) adopts IETF (Internet Engineering Task 
Force) standardized protocols like RTP, UDP, IP for the transport and packet-switch 
codecs like AMR (Adaptive Multi-Rate) and H.264 (MPEG 4 part 10) for encoding media. 
The 3GPP Packet Switched Streaming Services (see "Universal Mobile 
15 Telecommunications System (UMTS); Transparent end-to-end streaming service; 
Protocols and codecs", 3GPP TS 26.234 version 5.6.0 Release 5, September 2003, 
available at http://www.3gpp.org) use the RTP/UDP protocol stack to stream 
audio/video/text media. . 

• * 

RTP is . a Real-Time Transport Protocol (see Schulzrinne et al., "RTP: A Transport 
20 Protocol for Real-Time Applications", RFC 3550, July 2003, ail RFCs available at 

* 

http://www.ietf.org) which is mainly used for real-time or near real-time communication, 

« • * 

i.e. communication with relaxed delay Constraints. It provides information on the timing of 
the media it carries and ajso allows re-ordering and re-assembling at the receiver. 

■ 

« 

* ■ 

An integrated part of the protocol is RTCP (Real Time Control Protocol) which provides 
25 minimal reception information and loose group membership. RTP is generally used 

■ 

together with the RTP/AVP. profile (see Schulzrinne et al., "RTP Profile for Audio and 
Video Conferences with Minimal Control", RFC 3551 , July 2003) which defines the use of 
the RTP header fields and mapping tables for payioad types, besides simple RTCP 
feedback timing rules. 
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UDP (Postel, "User Datagram Protocol", RFC 768, August 1980) is the User Datagram 

• * . 

Protocol used to transport RTF packets. UDP is commonly used when an unreliable 
communication is appropriate for the given media, as is the case for streaming 
applications. The protocol stack RTP/UDP is used because the timing constraints of the 
5 media don't usually allow reliable communication, e.g. by using TCP (Transmission 
Control Protocol). 

In RTP, packetizatiori schemes (payload formats) for existing media formats (codecs) are 
specified in the Internet Engineering Task Force Audio/Video Transport Working Group 
(IETF AVT WG). There is, for example, a payload format for AMR encoded speech data, 

■ • 

10 and another one for H.264 video. 

* 

« 

The payload format defined in Hellstrom, "RTP Payload for Text Conversation", RFC 

* 

2793, May 2000, may be used to transmit conversational text but the format does not 
allow carrying any additional information on the decoration of the text characters. The 
decoration is for example the font used, the background color, the scroll or the karaoke 
15 movement It does not allow spatial synchronization with other media, like it is needed 

» . - 

e.g. for subtitling of video sequences. In summary, the 3GPP timed text (see 3GPP TS 
26.234, in particular Appendix D.8a) offers a much wider range of functionalities which is 
not supported by other standardized codecs. 

• * 

« 

* 

Rey et at., 'RTP Payload Format for 3GPP Timed Text", draft-ray-avt-3gpp-tt-01.txt, IETF 
20 AVT WG, September 2003, available at http://www.ietf .org suggests a payload format for 
the transmission of timed text using RTP. However, the payload format provides solely 
means for out-of-band transmission of sample description information and does not 
address the. problem of in-band transmission of sample description information in detail. 
The in-band transmission of sample description suggested by Rey et al. requires 
25 transmitting each sample description together . with its associated text sample and 
therefore can not solve the problems outlined below. 

In the present invention, in-band may be understood in the context of a signaling 
-channel— In general— the-sampte-descripttons re present pure sign aling information or 
metadata. The text may be considered the actual data. Thus in-band means that the 
30 signaling, i.e. the sample descriptions, is transmitted in the same session as the data, i.e. 
the text samples. Please note that the text samples do not contain SPLDESC, THDR or 
FHDR headers, just text strings and modifier boxes (see 3GPP TS 26.234) are 

« 

transmitted. Out-of-band signaling may be therefore understood as sending the sample 



WO 2005/046159 PCT/EP2004/011424 

3 

description using another session or protocol than the one used for transmitting the data, 
e.g. SDP. 

When streaming 3GPP Timed Text, it is typically the case that the streamed text samples 
refer to one and the same sample description entries. After a given amount of time all the 
5 possible sample descriptions have already been transmitted at least once. The text 
samples repeatedly refer to these sample descriptions and so the sample descriptions 

* • * 

must be transferred over and over again from sender to receiver since the sender does 
not know which packets were received by the receiver. Further, 3GPP TS 26.234 and the 
method proposed in Rey et al., "RTF Payload Format for 3GPP Timed Text" both require 
10 that each text sample is always transmitted along with its associated sample description. 
Hence, in conventional systems the transmission overhead due to transmitting, all sample 
descriptions of a 3GPP file is large. Further, this overhead is especially undesirable in 
case of providing streaming to a mobile client over a radio link scarce in its resources. . 

Summary of the Invention . 

« 

15 Hence; the object of the present invention is to reduce the transmission overhead of 
conventional systems when transmitting streamed text from a streaming server to a 
mobile terminal or client in a wireless communication system, such as UMTS, using RTP. 

■ 

The object of the present invention is solved by the subject matter of the independent 
claims. Preferred embodiments of the present invention are subject matter to the 
20 dependent claims. 

• * « 

According to a first embodiment of the present invention, a method for transmitting 
formatted text from a streaming server to a mobile client using an RTP protocol in a 

■ • * 

mobile communication system is provided- The formatted text may comprise at least one 
text sample having an associated text sample format description. The streaming server 
25 may determine whether a text sample format description for a text sample to be 

* 

transmitted has already been provided for an earlier text sample. If so, only the text 
sample to be transmitted may be added to at least one <data packet to be transmitted. If . 
Hnotrthe text sample to be transmitted and its associated text sample format-description- 
may be added to at least one data packet to be transmitted. The at least one data packet 

30 may then be transmitted to the mobile client 

• ... 

♦ « 

According to this embodiment the streaming server preparing a formatted text e.g. from 
a 3GPP file may analyze the text sample format descriptions of the different text samples 
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prior to transmission. In this processing the streaming server may determine which of the . 
sample descriptions have already been transmitted to the client or which of than may 

• * 

have been already been added to (an) RTP packet(s) to be transmitted to the client 
Depending on this determination process, the streaming server may not need to include 
5 . the text sample format descriptions in data packets in case same have been already 
provided. Hence, the transmission overhead may be reduced, as a (re)transmission of 
duplicated information may be prevented. 

■ 

Further, it should be noted that is also possible that a data packet comprises at least text 
one sample format description only. E.g. in case the maximum size for a single data 
10 packet Is already readied by the at least one text sample format description included, no 

additional text samples may be present therein. Hence, the different embodiments of the 

■ . 

present invention as outlined in the following paragraphs may also be applicable when 
data packets only comprise text sample format descriptions. 

■ 

■ 

There may be two possibilities in which the streaming server may not transmit the text 
. 15 sample format description, of a text sample to be transmitted: The text sample format 
description already provided has either been transmitted to the mobile client in an earlier, 
data packet or the text sample format description already provided has already been 

added to the at least one data packet when processing an earlier text sample.. 

• > ■ 

When adding the text sample to be transmitted to at least one data packet, the streaming 
20 server may further add at least one sample identifier to the at least one data packet The 
sample identifier may provide a mapping between a text sample format description and 

its associated text sample in the at least one data packet. Hence, by using an identifier, 

• ■ 

» ... 

each text sample may be correlated to a text sample format description. 

* 

According to a further embodiment of the present invention, the streaming server may 

• * 

25 maintain information on text sample format descriptions provided to the mobile client in 

the transmitted data packets. The maintained information may comprise data on the 

. provided text sample format descriptions, data on the at least one data packet in which 

'** * • * * 
------ the text sample format description has been transmitted, and the at least one identifier. 

■ • * 

■ * * ■ 

« • 

If it has been determined that a text sample format description for a text sample to be 
30 transmitted has already been provided for an earlier text sample it may be necessary to 
determine, which of the data packets transmitted to the client included the text sample 
format description. The information maintained in the streaming server may be used to 

- * 

determine the at least one transmitted data packet since same may comprise information 
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on the text sample format descriptions transmitted and the data packet(s) in which same 
have been transmitted or will be transmitted. 

If the streaming server determined that a text sample format description for a text sample 
to be transmitted has already been provided for an earlier text sample, i.e. in this case 
5 has already been transmitted to a client, it may be desirable to check, whether the at 
least one data packet comprising the text sample format description has been. 

• * 

* 

acknowledged by the mobile client If so, the sample identifier used in the determined at 
least one data packet for mapping the text sample to be transmitted to a provided text 

« • 

sample format description may be reused. I.e. the sample identifier used for the already 
10 transmitted text sample format description may be associated to the. text sample to be 

a - • 

transmitted and may be included into the at least one data packet in which the text 
sample to be transmitted will be included. 

If it has been determined that the determined at least one data packet has not been 

■ ■ 

4 

acknowledged by the mobile client, the text sample to be transmitted and its associated 

15 text sample format description may both, be added to the at least one data packet, since 

.**-•■ 

it can not be ensured that the mobile client has successfully received the necessary text 

* *. 

sample format description in the data packers) transmitted earlier. 

* 

Further, the at least one data packet may comprise a header and a payload section. The 
header of a data packet may comprise the reused identifier, if it has been determined 
20 that a text sample format description for a text sample to be transmitted has already 
been provided for an earlier text sample. In this exemplary embodiment of the present 
invention, a header in an RTP packet may comprise the sample identifier used for a text 
sample format description to indicate the text sample format description's reuse to the 

• * * 

receiving client Further, the text sample requiring the format specified in the text sample 
25 format description may also be associated to the. same identifier, such the client may 
map the text sample to its associated text sample format description. 

Moreover it should be noted that at least one data packet may comprise a plurality of text 

* * • 

samples and text sample format descriptions. It should be understood that' a single 'data T 
packet may comprise only a single text sample and/or text sample format description or. 
30 even only fragments thereof. Likewise, a single data packet may comprise a plurality of 
text samples and/or text sample format descriptions. 

* 

. * 

If it has been determined that a text sample format description for a text sample to be 
transmitted has not already been provided for an earlier text sample, the header of a 
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data packet may comprise at least one sample identifier and at least one text sample 
format description. 

In the alternative case, the header of a data packet may comprise at least one sample 

■ 

identifier since the text sample format description may be omitted as It has been provided 
5 earlier to the client 

As indicated above, the at least one data packet comprises a header and a payload 
section. Further, the payload section may comprise at least one sample identifier and at 
least one text sample. Hence, by the association of the sample identifier and the text 
sample of the payload section and the usage of said sample Identifier for a text sample 

* 

10 format description a mapping may be performed by the client to correctly format the text 

■ * 

sample. 

■ 

The determination whether a text sample format description for a text sample to be 
transmitted has already been provided for ah earlier text sample may be based e.g. on 
the maintained information. 

* • » 

15 Another embodiment of the present invention addresses the memory management for 
caching the sample description Information in the client to control the memory size 

« 

needed for caching. To reduce the size of required memory, only, a predetermined 
•■ ■ • * 

number of identifiers may be used. Hence, if it has been determined that a text sample 

format description for a text sample to be transmitted has not already been provided for 

. 20 an earlier text sample and if all available identifiers are used for mapping text samples to 

text sample format descriptions, an sample identifier may reused for the provision of a 

new text sample format description and the corresponding text sample to the mobile 

client 

Accordingly it is of advantage, that the maintained information on provided text sample 

* ■ 

25 format descriptions may be updated upon reuse of an identifier. 

« 

* 

To decide which sample identifier should be reused, the maintained information may 
further comprise a time stamp for each sample identifier indicating the latest insertion of 
the sample identifier into a transmitted data packet Hence, according to another 

* 

embodiment of the present invention, the sample identifier with the earliest time stamp 
30 may be reused for the transmission of a new text sample format description to the mobile 
client. 
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Further, it should be noted that the at least one data packet may only comprise at least 
one text sample format description* 

In another embodiment, the present invention provides a streaming server in a mobile, 
communication system transmitting formatted text to a mobile client using the RTP 
5 protocol. The formatted text may comprise at least one text sample having an associated 
text sample format description. The streaming server may comprise a packet forming 
means for forming at least one data packet, a processing means for determining whether 
a text sample format description for a text sample to be transmitted has already been 

provided for an earlier text sample, and a transmission means for transmitting the at least 

... 

10 one data packet to the mobile client. . 

* * * 

The packet forming means may be adapted to add the text sample to be transmitted to. at 
least one data packet to be transmitted, if the processing means has determined that a 
text sample format description for a text sample to be transmitted has already been 
provided for an earlier text sample. Further, the packet forming means may be adapted 
15 to add the text sample to be transmitted and its associated text sample format 

■ * ■ m « 

description to at least one data packet to be transmitted, if the processing means has 
determined that a text sample format description for a text sample to be transmitted has 
not already been provided for an earlier text sample. 

Moreover, the streaming server may be adapted to perform the method according to the 
20 different embodiments as described above. 

4 

* 

In a further embodiment of the present invention, a method for operating a mobile client 
in a mobile; communication system to receive formatted text from a streaming server 
using the RTP protocol is provided* Again, the formatted text may comprise at least one 
text sample having an associated text sample format description. The mobile client may 
25 receive at least one data packet from the streaming server, wherein the at least one data 
packet may comprise at least one text sample. Next, the client may determine whether 

♦ 

for a respective one of the at least one text samples, the at least one data packet further 
comprises at least one associated text sample format description. 

■ 

If so, the client may select the associated text sample format description for. the 

■ # 

30 respective text sample comprised in the at least one data packet directly from the data 
packet If not, a text sample format description for the respective text, sample may be 

■ ■ • 

selected from text sample format descriptions already available at the mobile client, as it 
may be assumed or indicated to the client that the required sample description has 
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already been provided to the client earlier. Upon having selected the appropriate format, 
i.e. text sample format description, the respective text sample may be formatted using 
the selected text sample format description. 

According to a further embodiment, the at least one data packet further comprises at 
. 5 least one sample identifier mapping at least one text sample to its associated text sample 
format description. 

In order to be abte to provide the appropriate mapping of text samples to text sample 
format description (received earlier) the client may maintain information on the text 

■ 

* 

sample format descriptions provided in received data packets. The maintained 

• ■ 

10 . information may therefore comprise data on the provided at least one text sample format 
description, and its at least, one sample identifier to be able to perform the mapping to 

* 

* ■ 

text samples. 

• * 
• ■ ■ 

When selecting the associated text sample format description for a text sample, the 

sample identifier associated to the text sample may be used to identify the associated 

* • * 

15 text sample format description in the at least one data packet or in text sample format 

■ » 

descriptions already available at the mobile client 

* 

« 

In case the client receives a new text sample format description associated with an 
sample identifier that is already associated to another text sample format description in 

« 

the maintained information, the maintained information may be updated based on a new 
20 text sample format description. 

To allow the streaming server to determine whether a text sample format description has 
successfully received by the mobile client, same may acknowledge the. at least one 
received data packet 

Further, a data packet received by the mobile client may comprise only at least one text 

■ •» 

25 sample format description and the mobile client may store the at least one text sample 

* * * 

format description received. Hence, it may be also possible to transmit/receive packets 
comprising sample descriptions only, arid to store same for later use when formatting an 
associated text sample. 

Another embodiment of the present invention relates to a mobile client for receiving 
30 formatted text from a streaming server using the RTP protocol. The mobile client may 
comprise receiving means for receiving at least one data packet from the streaming 
server, wherein the at least one data packet comprises at least one text sample, 
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processing means for determining whether for a respective one of the at least one text 
samples, wherein the at least one data packet further comprises at least one associated 
text sample format description, and text formatting means for formatting the respective 
text sample using the selected text sample format description. 

4 

5 The selection means may be adapted to select the associated text sample format description 
for the respective text sample comprised in the at least one data packet, if it is determined 
that for a respective one of the at least one text samples, the at least one data packet further 
comprises at least one associated text sample format description. Further, the selection 
means may be adapted to select a text sample format description for the respective text 

10 sample from text sample format descriptions already available at the mobile client, if it is 
determined that for. a respective one of the at least one text samples, the at least one data 
packet does not comprises at least one associated text sample format description. 

Moreover, the mobile client may be adapted to perform the different embodiments of the 
method as described above. 

15 According to a further embodiment, the present invention provides a streaming system 
comprising at least one streaming server and at least one mobile client. 

■ 

Brief Description of the Figures 

* 

In the following the present invention is described in more detail in reference to the 
attached figures and drawings. Similar or corresponding details in the figures are marked 
20 with the same reference numerals. 

FIg B 1 shows an architectural overview over the streaming system according to one 

embodiment of the present invention, 

Fig. 2 shows a payload header format for RTP according to one embodiment of the 

• * 

present invention, 

■ 

25 Fig. 3 shows a sample description field of the payload header shown in Fig. 2 

***** 

. according to one embodiment of the present invention, 



Fig. 4 shows the payload header format for RTP according to Fig. 2 having a 

reused text sample format description and a text sample format description 

» 

included in the header according to one embodiment of the present 

• ■ 

30 invention, and 
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Fig. 5 shows an enhanced version of payload header format for RTP shown in Fig. 

3 according to one embodiment of the present invention. 

* ■ 

Detailed Description 

Though the following description will be explained mainly in reference to 36PP timed-text 
5 streaming, it is noted that the principles underlying this invention may be readily applied 

* * 

to other text streaming systems in mobile communication systems, in which a text arid its 
format descriptions is streamed. 

a 

Fig. 1 shows an. overview of the system architecture according to an embodiment of the 
present invention. The streaming server 100 provides a streamed formatted text to the 
10 mobile client 101. In the exemplary architecture shown, the streamed data are passed 
through the Internet, i.e. via an IP based network (Internet) before they enter a wireless 

m « 

network, such as the UMTS 102. In the example shown, the GGSN 105 (Gateway GPRS 

• » 

Support Node) represents the gateway connecting the UMTS pore network (CN) 103 to 
the Internet. The data are passed through the CN 103 (via Serving GPRS Support Node 
15 SGSN 106) and through the access network, here UTRAN 104, to the mobile client 101 
via an air interface. The dotted arrow in the figure indicates the streamed data's delivery 
to the mobile client 101 through CN 103 and UTRAN 104. It should be noted that the 

* 

present invention is not restricted to the embodiment shown in Fig. 1. The streaming 
server may e.g. also be located within the UMTS network 102, data do not necessarily 
20 have to be delivered via an IP based network, other mobile communication systems than 
UMTS may be used, etc. 

■ 

According to one aspect of the present invention, the streaming server 100 may keep a 

* * . 

list of transmitted packets and some record of the sample description information entries 
sent in each RTP packet e.g. a list of SIDX values sent in each packet). Having this 
25 maintained information available, the streaming server 100 may compare the sample 
descriptions of the text samples currently processed for transmission with those included 
in transmitted data packets. The client may provide feedback to the server for these, data 

» • ♦ 

• ■ 

packets to avoid a retransmission of these sample format descriptions. Further, the client 
may elaborate a list of received sample description entries and store their corresponding 
30 sample description values. This record of received sample entries may have a minimum 
lifetime equal to the duration of the streaming session. 

* 

The following table will give an example for the list . or information maintained by the 
streaming server 100 in order to determine the association between sample identifiers 
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SIDX, sample descriptions and data packets in which the sample descriptions are/have 
been transmitted. 



• 1 

sampio 
identifier 
SIDX# 


• 

sample description 


1 

) m j 

RTP packets 


i < 

- • 1 

TX status 


• 

ACK 


s\Dxm 


SPLATTR#1 


SN#1 


TX 

I m • | 


I yes 


SIDX#2 


SPLATTR#2 


SN#2 


| ' TX 


yes 


SIDX#3 


SPLATTR#3 


SN#2 


TX 


yes 


SIDX#4 


SPLATTR#4 


SN#3 • • 


1 TX 


no ' 


SIDX#5 


SPLATTR#5 


SN#3, SN#4 


I . -TX i 


1 no. 


• • ■ 


• •• 

> 


• * 
• * • 


• •• 

•• 


• • • 


SIDX#N 


SPLATTR*N 

• 

• 


SN#Y 


i PENDING 


i no- 



The information gathered by the streaming server 100 on provided sample descriptions 

« 

may comprise the sample description and the RTP packets in which same have or are 
5 about to be transmitted to the mobile client 101. Moreover, the information may further 
comprise a sample identifier which facilitates the mapping between sample descriptions . 
and text samples. Further, in another embodiment of the present invention, the 
information maintained may further indicate whether all RTP packets carrying the sample 
descriptions have been transmitted (TX) or whether same are pending for 

• ■ ■ * 

10 retransmission, i.e. are currently prepared for transmission. Additionally, the 
acknowledgement status (ACK) of data packets in. which the sample descriptions have 
been transmitted may be also indicated. 

■ 

♦ * . 

The example given in the table above illustrates that e.g. the sample description 

SPLATTR#1 and has an associated sample identifier SIDX#1. Further, the sample 

15 description has been transmitted in a single RTP packet identified e.g. by its sequence 

number SN#1 to the client. According to the acknowledgement status the data packet 

SN#1 has been transmitted and successfully received by the. client Hence, a sample 

• * • * 

description of a new text sample to be transmitted by the streaming server 100 providing 
the same sample description as SPLATTR#1 does not have to be transmitted by the 

m 

20 server again. 

Taking the next sample descriptions SPLATTR#2 and SPLATTR#3. as an example, 
same have been transmitted in one RTP data packet (SN#2). Further, this data packet . 
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has also been transmitted and acknowledged by the client This example shows that also 
plural sample descriptions may be transmitted in one RTP data packet 

Next, sample description SPLATTR#4 has been transmitted in a single data packet 
(SN#3) which has not yet been acknowledged by the client In case a sample description 
5 identical to SPLATTR#4 is provided for a new text sample to be. transmitted, the 
streaming server 100 may (re)transmit the sample description again, since the data 
packet in which it has been transmitted to the client has not been acknowledged. 

• ♦ 

Alternatively, according to another embodiment of this invention, the streaming server 
100 may not retransmit the sample description again, assuming that all packets will be 

10 successfully received by the client, Le. also the RTP packets identified by SN#3 will be 
successfully received. Nevertheless, it should be noted that when delivering data 
streams in a packed switched network as the Internet, it may not be ensured that data 
packets arrive at the client in the order in which they have been transmitted by the 
server. Hence, in this embodiment a sample description transmitted prior to a text 

15 sample using the sample description may - in theory - arrive at the receiving client later 
than the text sample. 

Considering the sample description SPLATTR#5, the table above illustrates that the 
sample description has been transmitted split into two data packets, SN#3 and SN#4. 
Both RTP packets have been transmitted, but since at least the packet SN#3 has not 
20 been acknowledged, the sample description may not be considered available by the 

• m 

server. 

♦ 

■ * 

Further, taking the sample description SPLATTR#X it is noted that this description is 
identified by the sample identifier SlDXflX. Further, the data packet SN#Y in which the 
sample description is comprised is currently pending for transmission (PENDING). 
25 Hence, the RTP packet may be a packet that has been queued by the server for 
transmission or may be a RTP packet that is currently composed by the streaming server 

1 00, i.e. a data packet that is currently filled with information. 

■ • 

* 

In case data packet SN#Y has already been built but is still pending for transmission, 
there may be two possibilities for the streaming server 100 to act It may either assume 
30 that the data packet SN#Y may successfully received and omit the transmission of the 
same sample description for a new text sample using it, or may add the sample 
description to a new RTP packet again when a text sample using the description 
SPLATTR#X again. Assuming that the sample description SPLATTR#X is comprised in 
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the same RTP packet as a new sample description to be transmitted using the same 
description, the (retransmission of the sample description may be omitted for the new 

• * 

text sample. 

* * * 

In order to correctly format the received text samples, the mobile client 101 may maintain 
5 a similar list comprising the data of the first two columns of the table above. Maintaining 
information on sample identifiers and associated sample descriptions may allow the 
client to provide a mapping of received text samples to the appropriate sample 
description. The latter may be possible, since each text sample received in the payload 

of a RTP packet may comprise a sample identifier mapping the received text sample to 

* 

10 an associated sample description. 

■ « 
According to a further embodiment of the present invention, both streaming server 100 

and the receiving client, may implement advanced feedback capabilities, e.g. as 

described in Ott et al., "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" 

(draft-ietf-avt-rtcp-feedback-07.txt, IETF AVT WG, June 2003) or Friedman et al., "RTP 

15 Control Protocol Extended Reports" (draft-letf-avt-rtcp-report-extns-06.txt, IETF AVT WG, 

May 2003), both available from http://www.ietf.org. In particular the Loss RLE Report 

* « 

Block in section 4.1 of Friedman's draft and the ACK/NACK Messages of Ott's draft may 
. be used to inform the server about an exact loss/reception trace of data packets, i.e. 
which were received or lost. By employing these "extensions* to the common RTP 
20 protocol, individual packets may be acknowledged, such that a server receiving the 
acknowledgements may keep track of sample descriptions (text sample format 
description) transmitted to the client employing the server maintained list as described 

■ • 

above. 

- 

. ■ 

Hence, provided feedback on successfully received data packets at the client, the 
25 streaming server 100 may suppress redundant information in newer RTP packets. The 
streaming server 100 may check before including a sample description information into 
RTP packets, if the given sample descriptions have been transmitted in previous RTP 

♦ 

packets or whether they have already been added to RTP. .pa^ete^which are a,bout to be 

* ■ • 

transmitted by the streaming server 100. To ensure that a sample description sent in an 
30 earlier RTP packet has been already received by the client, the streaming server 100 
may further check whether RTP packets carrying such entries have been acknowledged 
by the client. In the latter case, the Inclusion of the entiles in the new RTP packet is 
redundant and thus can be avoided. Otherwise . the sample description information . 
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entries may be included as proposed in the draft "RTP Payload Format for 3GPP Timed 
Text" by Rey et al. 

In the following an exemplary format for me transmission of text sample format 
descriptions in a new payload header for RTP, will be discussed in reference to Fig. 2. 
5 Fig. 2 shows a SPLDESC (SamPLeDESCription) payload header for RTP according to 

* 

an embodiment of the present invention. The header comprises an initial entry count field 
followed by a number of sample identifiers SIDX and sample attribute SPLATTR pairs. 
Hence, this header may be used to transport text sample format descriptions of text 

« ■ 

samples to a receiving client The payload section of a RTP packet comprising this 
10 header may optionally comprise at least one text sample. The text sample may be 
. associated to a sample identifier SIDX which maps the text sample to a specific sample 
description having the same sample identifier SIDX. 

■ ■ 

The entry count may be an initial sequence of bits which indicates the number of entries 
in the header. In the example shown, two (0x02) entries may be included in the header 
15 (see Fig. 3). An entry may be defined as a pair comprising and SIDX field and an 
SPLATTR field. The entries may correspond to a particular text sample transmitted to the 
client 

The SIDX may represent the sample description index or sample identifier which is used 
to map the sample attributes in the SPLATTR field to one or more text sample. The 
20 SPLATTR field may comprise the sample description attributes transmitted in the 
' SPLDESC header. This field may contain the text sample default attributes as e.g. 
shown in the "tx3g" sample entry of Annex D.8a.16 in 3GPP TS 26.234. The length of 

* » 

this field may be variable. 

♦ 

■ * 

Further, the field may contain an initial byte with 1-bit flags. Each flag indicates if the 

■ 

25 corresponding field is present in the following bits. An example for the SPLATTR field in 
which all flags are set is. shown in Fig. 3 for illustrative purposes. The R (1 bit) may 
indicate reserved bit, D (1 bit ) a displayFlags flag, H (1 bit) a horizontal justification flag. 
V (1 bit) a vertical justification flag, B (1 bit) a background RGBA color flag, T (1 bit) a 
default text box flag, S (1 bit) a default style flag, and F (1 bit) a font table flag. 

* • 

■ 

30 The values for the "displayFlags" field (e.g. 16 bits), may indicate display options of the 
text: scroll in/out, scroll direction, karaoke or vertical text. If the H(V) bit is set the 
horizontal(vertical) justification field (8 bits) is present in the SPLATTR field. Further, e.g. 
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four octets (32 bits) may indicate the RGBA background color, if the B bit is set The 

• * 

older of the octets may be Red, Green, Blue and Alpha (transparency). 



If the T bit is set, the default text box field (e.g. 64 bits) is present This field may 
comprise four 16-bit values (top, left, bottom, right) that define the position of the text box 
5 in pixels relative to the text region origin. An S bit set in the field indicates the presence 
of a default style box field. To indicate which fields are present an additional byte (see 
figure above) of flags may be used. 

* ■ 

If the F bit is set the font table (variable size, 10 bytes in this example) is present. The 
font table may comprise an entry count field (16 bits) followed by a number of font 
10 entries. A font entry may comprise a font identifier font-ID (16 bite) from the font table, a 
font-name-length (8 bite providing the length of the font name in bytes, the font name e.g. 
expressed as a string of 8rbit UTF-8 characters The string may be a comma-separated 
list of font names to be used as alternative font, in preference order. 

As explained in previous sections during a 3GPP Timed Text session, the streaming 
15 server 100 may not be aware of the packets received by the client, in a general case. 
This is not the case if the client implements additional feedback capabilities as discussed 
above. With these enhanced feedback capabilities the client may be able to inform the 
server about every single packet that is received. With this piece of information and a list 
the server keeps of sent SIDX values in each packet it is possible to map the received 
20. packets to received SIDXs. The server may then only include those sample descriptions 
in new data packets that have not been received yet Hence, the overhead for when 
sending text sample format descriptions may significantly reduced. A flag byte in the 
SPLATTR field of the SPLDESC payload header may be set to all-zeros for sample 
descriptions (or SIDX values) to indicate to a receiving client that the attributed for the 
25 sample format have already been received by the client. An example format 
configuration is illustrated in Fig. A Note that for illustrative purposes only, a size of 8bits 
for the SIDX field length and entry count field is used. 



The entry count field indicated that two entries, i.e. two SIDXtSPI^TTR field pairs are 
included in the header. The sidx#i field is related to a sample description with the 
30 sample identifier 0x01 that has already been received or is not different from the 
defaults. This is indicated by setting the SPLATTR field to a predetermined bit 
combination, e.g. to set all bits of the field to 0 (splattr# 1=0x00). The sidx#2 field 

• ■ 

e.g. identifies a sample description with index number 0x02 whose horizontal and 
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vertical justification values differ form the defaults (splattr#i=Ox18=00110000 2 ). The 

• • • 

two octets (0x00, 0x00) following are set to zero and indicate top left justification (see 
also Fig. 3). 

■ 

Moreover,, for in-band transmission of text sample description the following rules may be 
5 applied to the coding of the fields: SIDX values present in text samples of the RTP 
payload may be included in a SPLDESC header of the same packet Hence, in this case 

♦ 

the RTP packet not only comprises the text format attributes but also the text sample the 
attributes belong to. It should be . noted that also more than one text sample in the 
payload may be associated to an SIDX value in the header. The corresponding format of 
10 the text samples, i.e. the SPLATTR field contents may be present unless the client has 

• • * ■ 

stored the SPLATTR contents for the given SIDX. In the latter case, both SIDX and 
SPLATTR may be omitted, since the use of extended feedback may allow the streaming 
server 100 to determine, which RTP packets are received by the client and consequently 
which text sample format descriptions are available at the mobile client 101s. 

15 All SIDX values present in the SPLDESC header of an RTP packet may be present in at 

* 

least one of the text samples in the payload. 

Additionally the RTP packets may carry only sample descriptions without any text 

» 

samples. For the latter case and using the same values as above a backwards- 

■ 

compatible structure of the SPLDESC header is shown in Fig. 5. 
20 The entry-count may comprise 7 bits as illustrated. The new F bit may be set to 1 if the 

» 

RTP packet only carries sample description information without any text samples 
following. The entry count is identical to the one shown in Fig. 3 if the bit F is set to 0 and 
thus the ■ RTP packet may both include sample descriptions and its associated text 

■ 

samples, complying with the rules given above. 

* ■ • 

• m. 

* I 

25 This optimization of the mechanism for sample description transmission presented may 

* * 

offer the possibility to reduce overhead in RTP packet transmission by informing the 
streaming server 100 about those pieces of information that the streaming client already 

possesses and does not have to send again. 

♦ . 

* » 

It also allows the transmission of sample description information only, without necessarily 

* • 

30 including the associated text samples. This further allows the server to specially protect 

* ■ 

or ensure the reception of such important information using repetition schemes or 
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forward error correction techniques as described by Rosenberg et al. in "An RTF 
Payioad Format for Generic Forward Error Correction", RFC 2733, December 1999. 

• ♦ 

According to a further aspect of the present invention, only a predetermined number of 
sample identifiers may be used. This may significantly reduce the buffer size for sample 
5 descriptions, at the mobile client 101. This may for example be of relevance, if a 
streamed text uses a large variety of text sample format descriptions. In the latter case 

• • • 

the client may have to store all sample descriptions when using the method described 

♦ 

above. To balance the tradeoff between reducing the transmission overhead and 
increasing the memory needed for the storage of sample descriptions, it may be 
10 considered to limit the number of available SIDX values to thereby limit the storage 

* • • 

capacity needed for sample descriptions in the client 

* 

According to a further embodiment of the present invention, the streaming server 100 

» . 

may only use a predetermined number of sample identifiers to map sample descriptions 
to associated text samples. Assuming that there are N sample identifiers available, the 
15 streaming server 100 may need to reuse, one of the sample identifiers upon processing a 
new text sample associated to the N+1* sample description. In this case the streaming 
server 100 may use different strategies to select the sample identifier to be reused. The 

■ 

simplest scheme would be to reuse the available sample identifiers cyclically. E.g. having 
using the sample identifiers SIDX#1 to SIDX#N and the sample description of sample 
20 identifier SIDX#1 may be overwritten, i.e. reused upon having associated all available 
identifiers with sample descriptions. 

■ 

Alternatively, the streaming server 100 may keep information on the latest usage of a 
sample description, i.e. a sample identifier and may e.g. reuse the sample identifier 
which has not been used for the longest time interval. Therefore the streaming server 

■ ■ * 

25 100 may maintain a list of information as shown below. 



sample 
identifier 
SIDX# 


sample 
description 


i • i 

! « * 
! • 

RTP packets 

i * 


timestamp 


; ■ 

i TX status 


\ ACK 


SIDX#1 | 


SPLATTR#1 


SN#1 


. TS#1 


TX. 


yes 


SIDX#2 | 


SPLATTR#2 


SN#2 


| TS#2 | 


| -TX- | 


yes 


SIDX#3 : 


SPLATTR#3 


SN#2 . 


' TS#2 


| TX j 


yes 


SIDX#4 i 


SPLATTR#4 


SN#3 


TS#3 


TX i 


no 


SIDX#5 


SPLATTR#5 


SN#3,SN#4 


TS#4 


TX j 


no 
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1 1 
1 1 

• 1 

* * * t • • • 1 


• • • 


* * * 


• • • 


• • • 


SIDX8X \ SPLATTR#X 

• ! ! 


SN#Y 


TS#X 


PENDING 

> 1 


no 



The table above mainly corresponds to the table shown in a previous section. Therefore 
the description of corresponding elements will be omitted. In the example above X is a 
predetermined value. 



• ■ 

In the table a column indicating the latest usage of the text sample by means of a 
5 timestamp have been added. Assuming that TS#2 is the earliest time stamp in the list, 

« 

the streaming server 100 may reuse SIDX#2 for a new sample description and may 
update the SPLATTR#2 field with the new sample description, in case there are no other 

* 

"empty" SIDX identifiers available. 

The reuse of a sample identifier may e.g. be established by simply transmitting a new 

• • * 

10 sample description using a used SIDX identifier, i.e. associating the sample identifier to a 
new description. The selection criteria for the sample identifier to be reused may further 
consider that text samples associated to the reused sample identifier and which have 
been transmitted prior to the identifier's reuse should be formatted by the client using the 
"old" sample description. Hence, a timestamp criterion as explained above may provide a 

1 5 good measure for these situations. 

Further, it should be noted that the client may not need to keep track of reuse criteria of 
sample identifiers. As soon as the client received a sample description together with an 
associated identifier, the maintained information at the client are updated, i.e. the 
identifier and the corresponding sample description may be stored independent of 
20 whether the sample identifier has already been used or not 



